Appendices A to D are a part of the present disclosure and each is incorporated herein by, reference in its entirety. A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The invention generally relates to generally to computer network management, and in particular to managing heterogeneous computer network elements.
2. Description of Related Art
Over the years, the organization of computer systems has changed dramatically. The concept of a large computer center with a single large computer to which all users bring their work is obsolete. The single large computer has been replaced by a large number of separate but interconnected computers that form a computer network.
There are many types of computer networks including Local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), Wireless Networks, and Internetworks. An Internetworks is a collection of of interconnected networks and is sometimes called an internet. The Internet is a specific worldwide internet. The widespread popularity of the Internet has resulted in yet other types of computer networks such as intranets and extranets.
A computer network includes both hardware and software. Typically, a network architecture is defined in terms a set of layers and protocols that define the communication between hardware and software in a computer as well as the communication between computers on the network. One widely used network architecture is the Transmission Control Protocol/Internet Protocol (TCP/IP) Reference Model. TCP/IP is well-documented and is known to those of skill in the art.
As computer networks have become more common, a number of new devices were introduced to facilitate communications between network computers including local and remote bridges, multiprotocol routers, distributed hubs, and switching hubs. Similarly, the number and diversity of computer platforms, both hardware and software, connected to a network increased. Typically, as each new product was introduced, a new user interface was introduced to those that managed the computer network. Each new user interface has its own terminology, commands, and navigational metaphor.
Hence, in the past few years, as computer network complexity has grown exponentially, computer network management challenges have grown similarly. The networks are too complex and too critical for any single person to manage alone. Even simple networks are typically managed by more than one network administrator.
To assist in the management of TCP/IP computer networks, a Simple Network Management Protocol (SNMP) was implemented. However, today, SNMP is used in proprietary network environments including Netware IPX/SPX, DECnet, AppleTalk, and SNA environments.
SNMP is an industry standard for managing heterogeneous TCP/IP-based computer network elements from a single management application. SNMP defines the protocols and message formats which are used to communicate between the management application and the computer network element. With SNMP, a network manager can configure computer network elements and monitor computer network performance and status. SNMP, version 1 is defined by several standards documents that include:
RFC 1155, xe2x80x9cStructure and Identification of Management Information for TCP/IP-based Internets,xe2x80x9d May, 1990;
RFC 1157, xe2x80x9cA Simple Network Management Protocol (SNMP),xe2x80x9d May 1990.
RFC 1212, xe2x80x9cConcise MIB Definitions,xe2x80x9d March, 1991; and
RFC 1213, xe2x80x9cManagement Information Base for Network Management of TCP/IP-based Internets: MIB-II,xe2x80x9d March 1991.
Each of the above documents is incorporated herein by reference to demonstrate the level of skill in the art for SNMP. As used in the standards document, RFC stands for Request For Comment.
A computer network 100 (FIG. 1), that is managed using SNMP, includes, for example, a management station 110, a workstation 120, a bridge 130, a router 140, and a printer 150. Network 100 also could include, for example, personal computers, repeaters, and hubs. SNMP is a client-server based application protocol. Management station 110 executes a SNMP manager application 115 that communicates with SNMP agent processes 121, 131, 141, and 151.
Specifically, SNMP manager 115 communicates with client processes, i.e., agent process 121 on workstation 120, agent process 131 on bridge 130, agent process 141 on router 140, and agent process 151 on printer 150 using SNMP. An agent computer process must be programmed for each of the computer network elements, and the actions that are to be taken must be specifically programmed for each computer network element.
Each of agent processes 121, 131, 141, and 151 monitors and controls the operation of the computer network element containing the agent process, i.e., elements 120, 130, 140, and 150 respectively, by maintaining a data base of objects 122, 132, 142, and 152, respectively, called the Management Information Base (MIB). The MIB reflects the status of the managed computer network element. Each of the agent processes 121, 131, 141, and 151 responds to network management requests from SNMP manager 115. An agent process can also send unsolicited messages, called trap events, to SNMP manager 115 to apprise manager 115 of network events. Manager 115 maintains statistics that define the operation of network 100 in MIB 112.
The SNMP standards define proxy agents that may be used to access management information from a remote device. A common usage of proxy agents is to translate protocols when the remote device does not support SNMP.
SNMP uses well-established standards to define the format, content, and database structure of management information objects that are stored by the agent process and passed between SNMP manager 115 and the agent. These objects are carried in packets called protocol data units (PDUs) and contain operating parameters, statistics, and control information for the element and its components. The objects (variables) comprise the MIB. The current version of the MIB definition as defined by the standards body is MIB-II. Any SNMP management process can access MIB-II data.
The MIB may be extended beyond the standard set of objects to include objects specific to the agent by incorporating a private vendor-specific enterprise MIB. MIB objects are grouped according to functionality and are categorized in a tree-like data structure. The tree is comprised of a root, branches, and leaf nodes The leaf nodes represent MIB object instances and can be located by traversing the tree as deeply as possible. To simplify the traversal process, each branch at the same level in the tree is assigned a lexicographically ordered number. Thus, each node in the tree is representable by a sequence of period-separated numbers, where each number is associated with a branch level. The sequence of numbers is known as the object identifier (OID). FIG. 2 illustrates a portion of the MIB-II tree and how object identifiers are assigned. From FIG. 2, one can determine that the object identifier for the system group is 1.3.6.1.2.1.1.
RFC 1157, xe2x80x9cA Simple Network Management Protocol (SNMP)xe2x80x9d describes the operation of SNMP by stating:
The network management protocol is an application protocol by which the variables of an agent""s MIB may be inspected or altered. Communication among protocol entities is accomplished by the exchange of messages, each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN.1. A message consists of a version identifier, a SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps (i.e., all messages except those which contain the Trap-PDU). Messages which report traps should be received on port 162 for further processing. An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible.
Compliance with SNMP, version one standard (See RFC 1157, page 16) requires that all implementations of SNMP support five PDUs, i.e., GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, and Trap-PDU. The five PDUs are described in detail in TABLE 1.
By using these operators, a SNMP manager application can communicate with managed nodes to identify the nodes, and to determine statistical information, such as network traffic flow through a given computer network, for the network.
SNMP trap events allow the SNMP agent to initiate communication with management applications when a significant (serious) network event takes place. The significant trap events are defined in RFC 1157. By default, all SNMP agents generate Trap-PDUs for the events shown in TABLE 2.
In contrast to trap events, polling events are proactive requests made by management station 110 to elicit information from the agent. A common network management technique called xe2x80x9ctrap directed pollingxe2x80x9d is for the management station to wait for a trap event and then poll for more information regarding that event. This method minimizes the impact on managed elements and network bandwidth. However, since traps are sent unreliably, some degree of polling is still required as a backup precaution.
Access to an agent is controlled by a community name. Every agent is configured to recognize one or more community names, and to provide the appropriate level of access to SNMP managers based on the community name that the managers include in their messages.
The community relationship between agents and managers defined by the community name is used to administer the MIB and to provide the agent information on where to send a trap. There are three levels of access to MIB objects: read-only(object value can be read but not modified), read-write (object value can be read or modified), and write-only (object value can be modified but not read). The level of access which the agent allows for its MIB objects is determined by comparing the community name provided in the SNMP message with that defined by the agent. If the two names match, access is given. A separate community name is defined for read and write accesses. The most common community names are public (access given to all management stations) and private (no access allowed). Community names are not considered passwords because community names cannot make any guarantees regarding the command (message) with respect to its origin, its integrity, its delivery, or its privacy. More information regarding community names is contained in RFC 1157.
While SNMP was designed to simplify network management, this has not be the case. To make SNMP successful, every device vendor must provide tools to monitor and troubleshoot their devices, or alternatively get some other company that supplies a management system to include support for their particular device. In general, the communication of vendor specific MIB objects among heterogeneous elements is problematic.
The challenge is clear. How can a group of network managers efficiently manage a constantly changing and growing network which is composed of a wide array of heterogeneous elements, that are produced by different vendors, and that support many different platform types? Any solution must be simple, flexible, robust, secure, collaborative, and most importantly has to work.
A managed element server of this invention is a comprehensive open, standards-based network management solution for computer networks having a computer network management capability. The managed element server of this invention efficiently manages a constantly changing and growing heterogeneous computer network. The solution of this invention, as described more completely below, is flexible, robust, secure, collaborative, and most importantly works.
The client-server network management system of this invention includes: a plurality of managed computer network elements, sometimes called managed elements; a managed element server that executes on a first computer; and at least one managed element server client that typically executes on a second computer. The managed element server and managed element server client are computer processes that execute from memory of their respective computers.
The managed element server and managed element server client are platform independent computer processes and can be executed on any computer platform that supports the platform independent computer language in which the server and client are written. This is particularly advantageous because it is unnecessary to write a different version of the client and server for each of the different computing platforms typically found on a heterogeneous computer network.
The client-server network management system provides a new capability for creating a managed element template, called an element manager, for a management-enabled computer network element, such as a bridge, a workstation, or perhaps, a computer software application that is executing a computer system connected to the network. A user can build an element manager without writing any computer code. In addition, a user can edit an element manager without writing any computer code. Moreover, since the computer processes are platform independent, the user does not need to be working on a particular type of computer platform to build an element manager. The user utilizes an intuitive graphical user interface (GUI) not only to builder element managers, but also to utilize the managed element server of this invention in managing computer network elements.
The graphic user interface of this invention, that is displayed by the client, includes a visual image of a computer network element being managed. The visual image includes a representation of the components of the computer network element, which include for example active components such as ports; a set of LEDs, and action buttons that are typically used to change the state of the computer network element. The user can select one of the components by clicking on a representation of the component in a navigation tree that is displayed in a navigation area of the graphic user interface, or alternatively by clicking on the component in the visual image.
The user can configure an element manager for the managed computer element represented by the display in graphic user interface so that a managed component, called a hotspot, has either a colored outline about component or the component itself has a color. The color of the outline or the color of the component itself gives the user a visual representation of the status, e.g., state of the component. Thus, as a user looks at the visual display in the graphic user interface, the user is provided the same visual information as if the user where physically present at the location of the managed computer network element. Thus, at a glance, a user can obtain considerable information about the status of the computer network element as represented by the visual display.
An alarms button in the graphic user interface flashes when the managed computer network element experiences an event that is associated with a alarm. This notifies the user that action may be required in management of the computer network element. The user can determine why the alarms button was activated by reviewing an alarm log that is presented in the graphic user interface upon the user activating the alarms button.
Using the client graphic user interface, the user can initiate action that corrects a problem that generated the alarm, or alternatively, configure the server to automatically correct such problems. Also, the user can change the management configuration for the managed computer network element by redefining rules that are used in event management to monitor and control the operation of the managed computer network element.
Through the graphic user interface, the user can configure the server to periodically send user-defined polling event requests. The managed computer network element replies with the requested information to the server. Depending on the configuration of the server, predefined actions may be executed in response to polling events. The event management also supports trap-directed polling. Thus, any user can manage the computer network from a computer connected to the network without being physically present at the location of each managed computer network element. Further, the user does this by using any computer that can be connected to the network independent of the processor or operating system on the computer, and without writing any computer code.
Hence, the intuitive client GUI of this invention makes client-server network management system easy to use and hides its complexity. The GUI presentation is separated from the application logic in the server and this reduces hardware requirements, provides scalability and extensibility, and increases the flexibility of the client-server network management system.
The client-server network management system of this invention is really two applications in one: a visual element manager builder and a manager. The visual element manager builder is a visual development environment in which device vendors or network managers may create standardized element management applications, called element managers. The manager provides the run-time environment in which the element managers are executed to monitor and manage computer network behavior such as network throughput, collision rate, and number of duplicate IP packets, to name a few. No programming is required and the separation between the visual element manager and the manager is seamless and transparent to the user.
According to the principles of this invention, one of a plurality of element managers is associated with each managed computer network element in the computer network. Herein, a management-enabled computer network element is any element in a computer network that can be managed using a computer network management protocol. A management-enabled computer network element can be any hardware or software on the computer network that implements the network management protocol by having a network management agent and a network management information database, or a similar process.
The manager of this invention includes a discovery engine that automatically interrogates each host in the computer network to determine whether the host is running a network management agent. Upon detection of a management-enabled computer network element, the discovery engine attempts to associate one of the plurality of element managers with the computer network element. If the discovery engine is able to associate the computer network element with one with one of the plurality of element managers, the discovery engine calls a process that uses the element manager to create a managed element object, and creates a poll server and an event engine for the managed computer network element. Upon completion of the discovery of management-enabled computer network elements, each management-enabled computer network element either has a managed element object and an associated poll server and an event engine, or is assigned a predefined element manager name, if no association could be made.
A poll server in the manager of this invention creates a thread for each polling event (request) specified in poll events of the managed element object. When the poll server receives a response to a polling event, the data in the response is passed to the event engine for evaluation. The managed server element allows polling events which are used to solicit the information from a computer network element, or any of its components.
The event engine in the manager of this invention, in one embodiment, is an event rule engine. The event engine process all polling events, and all trap events for the managed computer network element associated with the managed element object. The event engine uses event rules to determine the action that should be taken in response to each polling event, and each trap event. Each rule has a rule condition, and a rule action. The event engine evaluates the rule condition using the data from the polling event or trap event, and if the rule condition is true, performs the action or actions specified by the rule action.
The combination of the event engine and the event rules is a sophisticated state machine and rules engine which allows pro-active management of a managed computer network element. Each active component of a managed computer network element has states, which are defined within the managed element object. These states are used in event rules to accurately manage a device, by triggering alarms based on sequence of events rather than simple threshold conditions, or by taking some other prescribed action.
In response to the result of a poll of the managed computer network element, the event engine determines the current state of the element component for the poll event. Next the event engine loops through all the rules in event rules for the polling event to determine whether there is a rule that can be applied for the current state. If there is such a rule, the event engine uses the information returned in the result of the poll to evaluate the rule. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. The action specified in the rule can be one or more of: executing a system command, logging an event to the alarm log, and changing the state of the element component from the current state.
In response to a trap event from the managed computer network element, a trap server passes data in the trap to the event engine which in turn determines the current state of the element component that generated the trap. Next the event engine loops through all the rules in event rules for the trap event to determine whether there is a rule that can be applied. If there is such a rule, the event engine evaluates the rule using data sent in the trap. If the rule is true, and any persistence condition is satisfied, the action specified in the rule is executed. If there is no rule for the trap in the event rules, the event engine logs the trap into the alarm log for the computer network element.
After an alarm factory in the manager of this invention loads an existing alarm log for each managed element object. The user can view the alarms for all managed computer network elements, for a group of managed computer network elements, for a specific computer network element, or, for a component of a specific computer network element. When an alarm is received, button Alarms on the client GUI changes state, e.g., blinks, and if the alarm is associated with a particular component, the appearance of the component may be changed in response to the alarm.
The trap server, in the manager of this invention, receives all traps from other hosts on the computer network. If a received trap is from one of the managed elements, the trap server copies the data in the trap to a buffer, and notifies the event engine for the managed element that generated the trap. The event engine processes the trap data as described above.
Notice that the manager portion of managed element server described above is independent of any graphic user interface. The logic and structure of the manager of managed element server is cleanly separated from the graphic user interfaces
The managed element server also interacts with managed element server clients. In one embodiment, the managed element server client is implemented as a JAVA applet and is running inside a World-Wide Web Browser or a JAVA Applet Viewer. The JAVA applet is downloaded from the managed element server. The JAVA applet includes information that allows a user a) to monitor the operation of each of the managed computer network elements, b) to edit the event management for the managed computer network elements by reconfiguring the event management model in the element manager object for the network element, and c) in one embodiment, to use a visual element manager builder that permits both building and editing of element managers.
The element manager of this invention is a template that is used by the manager in the server of this invention to manage a computer network element. The element manager includes basic information data that defines core properties of a computer network element, and event management information that is used in managing the computer network element.
A method for building an element manager for a computer network element includes entering data characterizing the element manager through a graphical user interface of a client computer process. The client computer process uses a visual element manager builder server process to build the element manager using the data. The element manager is stored in a memory on a computer that executes the server process for the client computer process.
The basic information includes a storage location of a file that contains a visual representation of the computer network element; identification of attributes that characterize operation of components of the computer network element; association of a component of the computer network element with one hotspot in a plurality of hotspots; association of attributes that characterize operation of the component with the one hotspot. All of this basic information is entered using element manager build panels in the client graphic user interface. The element manager build panels include a plurality of wizard panels. In one embodiment, a wizard panel is identified by a plurality of edit command buttons.
The event management information includes: states for a component of the computer network element; polling events for the component; a requisite component state or states for each polling event; a rule for each polling event when the component is in the requisite component state; and trap events for the component. All of this event management information is entered using element manager build panels in the client graphic user interface. The element manager build panels include a plurality of wizard panels.
Hence, in this embodiment, the element manager builder tool is downloaded from the computer server process and executed as a client process wherein the element manager builder tool presents a user with a plurality of panels in a graphic user interface to build the element manager.